For businesses to be competitive online, a business must provide a feature rich browsing experience for their content sites and provide content pages that include both static and active elements. Often, the active elements allow for a user to provide text input, which in different cases may be sent to be processed remotely at a web server providing the content page. In the case where a user is bad actor, the user may provide as input malicious scripting data, which when executed on the web server, may cause the web server to provide security compromised content pages to multiple other users. Such an instance is a cross-site scripting attack. Further, cross-site scripting is a widely prevalent web application security vulnerability.
Traditional approaches for preventing cross-site scripting rely on either output encoding or input filtering. Input validation requires developers to perform whitelist filtering of untrusted data at the point that the data enters the trusted system. However, some problems with this approach are that, outside of environments where data gathering and consumption are performed within a same application, whitelisting does not scale to large applications. Further, complex types of data, such as free text or rich text, may validly include characters that may trigger a cross-site scripting attack. Blacklist filters are ineffective due to new attacks being constantly created. Output encoding requires developers to encode data when it is injected into a web page that is to be rendered in a web browser or other client application. Output encoding also requires that developers configure application frameworks to encode all data injected into a web page to be encoded by default. However, in complex architectures, content in a web page may come from different sources, which hinders a consistent enforcement of application frameworks.
Recent versions of HTTP and HTML provide for a mechanism, a setting of a content security policy (CSP), to define a whitelist of valid sources from which active content may be executed to render content. However, a straightforward use of CSP features still leaves security vulnerabilities against cross-site scripting attacks.
While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that the embodiments are not limited to the embodiments or drawings described. It should be understood that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include”, “including”, and “includes” mean inclusive of, but not limited to.